Design Comments:

A unique identifier for this particular event assigned by the system in which the event occurred.

UsageNotes:

Identifier needs to be persisted by receiving applications, except for queries (queries cannot be retracted or undone). The identifier must be unique and different from the event identifier that is present on the request - it must be generated by the responding application.

Rationale:

Allows the event to be referenced (for undos) and also indicates whether multiple interactions were caused by the same triggering event. Also used for audit purposes.

Design Comments:

Identifies the trigger event that occurred.

Rationale:

This is mandatory because it is essential to understanding the meaning of the event.

Design Comments:

Describes the status of the control act, which is always complete (it happened).

Rationale:

Required for completeness of specification.

Design Comments:

Indicates the time the event (e.g. query, change, activation) should begin and occasionally when it should end.

Rationale:

The time an event becomes effective may differ from the time the event is recorded (i.e. it may be in the future or the past). For events such as 'suspend', an intended end date may also be indicated.

Design Comments:

Identifies why this specific message interaction (e.g. query, activation request, modification request) occurred.

UsageNotes:

The domain associated with this attribute will vary for each interaction and will be noted as part of the interaction description.

Rationale:

Allows identifying a reason for a specific action, such as 'reason for hold' or 'reason for accessing information'.

Design Comments:

Indicates the person responsible for the event that caused this message.

Rationale:

Critical for auditing and for validating permissions and therefore mandatory.

Design Comments:

Indicates the item(s) being acted upon by this trigger event.

Will be mandatory in wrappers with payload messages, otherwise not present.

UsageNotes:

If there are multiple subject items, the changes to all of them must be either accepted or rejected as a single action. I.e. One trigger event = 1 unit of work.

Rationale:

Provides information about the thing being created, modified or removed.

Design Comments:

Information pertaining to a client's (or provider's)agreement/acceptance to have his/her client/provider identification and demographic information electronically stored and shared.

Rationale:

Provides authorization to record and/or view client/provider information.

Indicates the consent or keyword used to authorize access or update, including a reason for access; May also be used to override access restriction to the information ('break the glass') on a message by message basis.

Design Comments:

This is the list of clinical and business issues that have been detected and/or managed involving the current action.

Rationale:

Any trigger event can result in errors or may allow for errors to be overridden or managed.

UsageNotes:

Value should always be AUT

Design Comments:

The time the person responsible for the event made the decision for it to occur. This may be different than the time the change became effective. (E.g. If a provider decides today to put a prescription on hold starting next Tuesday, the time of creation would be today and the change effective period would be next Tuesday.)

This date can be back-dated.

Rationale:

The time a change is made is a critical piece of audit information and is therefore mandatory.

Design Comments:

Indicates how the person who recorded the event became aware of it.. E.g. Verbal, written, fax, etc.

Rationale:

May have ramifications for the audit trail and reliability of the information.

Design Comments:

Indicates whether or not objects of the trigger event are to be cascaded to the payload.

If true, associations in the parent act are conducted across the ActRelationship to the message payload (act). Conduction for each association is specifically indicated by each associations' contextControlCode value.

In other words, if the "subject" act relationship has contextConductionInd=true; THEN the subjectOf association is carried (to the regsitrationRequest act) according to the subjectOf.contextControlCode (AP = propogate to the reg request and add to any subject(s) (issues) already present in the payload).

Rationale:

Cascading of trigger event objects allows different messages to employ consistent and common objects.

Attribute is mandatory to ensure that cascading will be specified one way or another.

Design Comments:

This class contains information relevant to the registration of the payload item(s) into the Master File or Registry. This message is a request to register.

Rationale:

The RegistrationProcess act is the focal act of the message and therefore is mandatory

Design Comments:

Commonly called the Payload stub. Any interaction that uses this ControlAct Wrapper will replace this class with a Role-based domain Message Type

Rationale:

Defines the content of the registration and is therefore mandatory.

Design Comments:

This indicates the EHR repository the record is stored in.

Rationale:

Different repositories may have different access rules governing access to data. Knowing the custodian of the data also helps to provide context. As a result, this association is mandatory.

Design Comments:

Identifies "duplicate" records of the registered item that have been superseded by this record.

Rationale:

Provides support for merges.

Design Comments:

Identifies "duplicate" records of the registered item that have been superseded by this record.

Rationale:

Provides support for merges.

Design Comments:

An authentication token expressed as a non-GUID string.

The Authorization token may represent the concepts of author, data enterer, supervisor (responsible party), responsible location and/or data entry location.

Rationale:

Some systems may choose to use a hashcode or other approach to token construction.